Virtual os computing environment

ABSTRACT

Multiple, semi-independent virtual operating system (OS) environments coexist within a single (OS) such that a change made in one environment does not affect the main OS or any other environment. In this way each virtual OS environment appears to be an independent OS for the applications running within it. The file system and registry information for each environment is independent of the base OS and other environments. Each of the environments can contain a group of installed applications that will run independently of each other. Although the invention is described in terms of a Windows® environment, the approach is applicable to other operating systems through appropriate modification.

REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.10/716,337, filed Nov. 18, 2003, which claims the benefit of U.S.provisional patent application Ser. No. 60/427,339, filed Nov. 18, 2002,the disclosures of which are each incorporated herein by reference intheir entirety.

FIELD OF THE INVENTION

This invention relates to computing environments and, in particular, tothe creation of multiple, semi-independent virtual operating system (OS)environments within a single OS.

BACKGROUND OF THE INVENTION

An Operating System (OS) is the high-level software that allows users tointeract with a computing machine and run programs (i.e., applications).To enhance the versatility of computers, virtual operating systems (VOS)and programs that implement virtual machines (VM) have been developed.Using such systems, applications “expecting” a particular OS may run ona machine executing a different OS, or commands generated by anapplication may cause a real computer to act like the imaginary machine.Theoretically, a VOS may allow the same program to work on virtually anymachine running the Virtual OS, thereby supporting “instant portability”for new machines.

The concept of a virtual machine has been popularized by Pascalcompilers which produce intermediate “p-code” and, more recently, byJava language from Sun Microsystems. Whereas most compilers produceobject code for one family of CPU, Java compilers produce object code(called J-code) for machines that may or may not exist. For eachphysical target processor, a Java interpreter, or virtual machine,“executes” the J-code. This allows the same object code to run on anyCPU for which a Java interpreter exists.

Other examples include Limbo, a programming language developed at LucentTechnologies, produces object code for an imaginary CPU, and Perl, whichcreates an intermediate program representation and executes thisintermediate representation instead of creating native executable code.

The major standard operating systems, namely Windows, Macintosh andUnix, make very different “calls” to the OS. These calls are critical towriting sophisticated applications, which limits portability. Javasolves this problem by providing a set of library functions thatcommunicate with an imaginary OS and imaginary GUI (graphical userinterface). In a sense, just like the JVM presents a virtual physicalmachine, the Java libraries present a virtual OS/GUI. Every Javaimplementation provides libraries implementing this virtual OS/GUI. Javaprograms that use these libraries to provide needed OS and GUIfunctionality port fairly easily.

Virtual operating systems include the Amiga OS, which is based on theTaos Elate OS, and Inferno developed by Lucent Technologies. Inferno, avirtual operating system running on top of the Linux operating system,is targeted to creating and supporting distributed services used in avariety of network environments, including advanced telephones,hand-held devices, TV/cable/satellite set-top boxes, Internet computersand conventional computing systems. Applications use various resourcesinternal to the system, such as a consistent virtual machine that runsthe application programs, together with library modules that performservices as simple as string manipulation through more sophisticatedgraphics services for dealing with text, pictures, higher-leveltoolkits, and video. Applications exist in an external environmentcontaining resources such as data files that can be read andmanipulated, together with objects that are named and manipulated likefiles but are more active.

SUMMARY OF THE INVENTION

This invention is directed to the creation of multiple, semi-independentvirtual OS environments within a single operating system (OS). A changemade in one environment does not affect the main OS or any otherenvironment. In this way each virtual OS environment appears to be anindependent OS for the applications running within it. The file systemand registry information for each environment is independent of the baseOS and other environments. Each of the environments can contain a groupof installed applications that will run independently of each other.Although the invention is described in terms of a Windows® environment,the approach is applicable to other operating systems throughappropriate modification.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified diagram showing the creation of multiple OSenvironments under a single OS;

FIG. 2 is a illustrates the creation of independent locations for filesystems and registry within the base OS file system and registry;

FIG. 3 shows how, according to the invention, injected DLL functions canexecute code both before and after the OS API function;

FIG. 4 shows how any applications that are run from under the virtual OSenvironment file system are always redirected into that virtual OSenvironment;

FIG. 5 depicts when application is being redirected into a virtual OSenvironment, it makes an API call that tries to access the file systemor registry, causing the API to be redirected to a function in theinjected DLL;

FIG. 6A is a diagram that shows how getting and setting of the currentdirectory are redirected into the virtual OS environment.

FIG. 6B shows how injected DLL functions maintain lists of these handlesand the pathnames that they reference. These lists are then used insubsequent calls to OS API functions to modify the parameters properly;and

FIG. 7 is a diagram that depicts how OS API calls can be redirected bythe injected DLL function modifying a parameter sent to or returned fromthe OS API.

DETAILED DESCRIPTION OF THE INVENTION

This invention is directed to the creation of multiple, semi-independentvirtual OS environments within a single operating system (OS). A changemade in one environment does not affect the main OS or any otherenvironment. In this way each virtual OS environment appears to be anindependent OS for the applications running within it. The file systemand registry information for each environment is independent of the baseOS and other environments. Each of the environments can contain a groupof installed applications that will run independently of each other.Although the invention is described in terms of a Windows® environment,the approach is applicable to other operating systems throughappropriate modification.

The applications running within the virtual OS environments still sharethe base OS attributes such as networking information, user loginrights, services, hardware information, and the Windows clipboard. Inaddition, all of the applications run on a single OS desktop. The enduser does not need to be aware that the applications are being run fromdifferent virtual OS environments. While the applications share the baseOS attributes, the changes made to configuration information is madeinto the virtual OS environment and not into the base OS.

The virtual OS environment is achieved by creating independent locationsfor file systems and registry within the base OS file system andregistry. When applications attempt to access the file system orregistry, the attempt is redirected to the virtual OS environment filesystem or registry instead of the base OS location.

To create the virtual OS environments, the OS APIs that access the filesystem and registry directly and indirectly must be changed to redirectthese accesses into the virtual OS environments file system andregistry. This is done by injecting a DLL into every application that isexecuted. This DLL first must determine whether the current applicationshould be run under one of the possible virtual OS environments or thebase OS. If the current application is to run under the base OS theinjected DLL does nothing and the application runs normally. If thecurrent application needs to be redirected into a virtual OSenvironment, the injected DLL scans the applications function importtable and redirects all file system and registry API calls to insteadcall functions within the injected DLL itself. This is done for theapplication functions and all of the DLLs that are loaded by theapplication. In addition, Windows COM calls that access the file systemor registry are also redirected by the injected DLL.

When the application (or one of the applications DLLs) attempts to callan OS API (directly or indirectly) that will access the file system orregistry, the injected DLL's function is called instead. The injectedDLL's function then examines the parameters that are passed to the APIand modifies them to direct them into the virtual OS environmentlocation instead. The injected DLL's function then calls the real OS APIwith the modified parameters to perform the required function. Lastly,the injected DLL's function returns to the calling function, returningany information from the OS API function. This returned information isalso modified to convert the file system or registry locationinformation back from a virtual OS environment location. Using thismethod, the injected DLL functions can execute code both before andafter the OS API function.

As mentioned earlier, not all applications are run from virtual OSenvironments and different applications may be run from differentvirtual OS environments. When the injected DLL is first loaded it mustdetermine which of the virtual OS environments (if any) to redirect to.This must be done for the current application as well as any spawned orchild processes created by the current application. This is determinedbased on the location of the current application EXE in the base OS filesystem. The base OS contains a list of directories where applicationsshould be redirected to specific virtual OS environments. Anyapplication EXE that is executed in this directory or optionally a childof this directory will run under a specific virtual OS environment. Thisis can be set to a CD/DVD drive in the base OS file system and theapplication run from this location is often a application installationprogram. Note that this directory is added to the virtual OSenvironment. File system accesses to this directory (or children) willnot be redirected but will be performed in the directory itself. Thisdirectory (or directories) are shared by the base OS and the virtual OSenvironment. This allows the installation program or application toaccess support files that are then installed into the virtual OSenvironment.

In addition, any applications that are run from under the virtual OSenvironment file system (ex: C:\VirtualEnvs\Env1) are always redirectedinto that virtual OS environment. Since the temporary directory is alsoredirected into the virtual OS environment, if an installation programextracts additional installation programs from itself into a temporarydirectory and then executes them, they will be redirected into the samevirtual OS environment. Since the installation program can only makechanges to the virtual OS environment and the shared directory, it canonly place files into a location that is under the virtual OSenvironment itself. It cannot change any file system or registryinformation in the base OS file system or registry except in shareddirectories. This method guarantees that the proper applications arealways running in the proper virtual OS environment or base OS and thatthe applications can only modify specific areas of the base OS filesystem and registry.

Because all of the file system and registry calls are redirected, a copyof the base OS file system and registry must be created in the virtualOS environment file system and registry before any applications may beexecuted in the virtual OS environment. Once this is done, any built-inOS applications that are run by applications within the virtual OSenvironment (such as Notepad, WordPad, or Internet Explorer) will beexecuted from the virtual OS environment copy of that application. Thiswill allow multiple versions of built-in OS applications to be supportedat the same time in different virtual OS environments.

When an application that is being redirected into a virtual OSenvironment makes an API call that tries to access the file system orregistry, the API is redirected to a function in the injected DLL. Thisis done without any modifications required to the application or supportDLLs.

This redirection is done for all OS API calls that access the filesystem. There are file system calls that use a relative path. Thesecalls are relative to a current directory. The getting and setting ofthe current directory are redirected into the virtual OS environment.The application views that it is accessing/modifying the base OS filesystem or registry when in fact it is accessing/modifying the virtual OSenvironment file system and registry.

The redirection of registry information is done the same way as filesystem information. All calls that access the registry are redirectedinto the injected DLL functions where they modify the parameters toredirect that registry access to a section of the registry that isprivate to the virtual OS environment. A number of registry and filesystem APIs are passed handles instead of a specific pathname. Theinjected DLL functions maintain lists of these handles and the pathnamesthat they reference. These lists are then used in subsequent calls to OSAPI functions to modify the parameters properly.

Since all of the virtual OS environment information is isolated insideof the base OS file system and registry, it becomes easy to save, store,and load entire virtual OS environments. It is therefore convenient tocreate a virtual OS environment that contains a set of applicationsconfigured in a specific way (or a “clean” virtual OS environment thatcontains no applications yet) and store it in a separate or centrallocation to be used by multiple computers or the same computer atdifferent times.

Not all OS API calls can be redirected by the injected DLL functionmodifying a parameter sent to or returned from the OS API. For examplewhen creating a shortcut using the Program Manager DDE calls, theshortcut is created in the base OS file system (after backing up anyshortcut in that same location) and then moved into the virtual OSenvironment file system. Afterward, any shortcut that was in the base OSfile system is then restored. This occurs within the injected DLLfunction that is called from an application in the virtual OSenvironment.

Another special case occurs when a 16-bit application is to be executedwithin the virtual OS environment. The injected DLL does not functionwith 16-bit applications so this is normally not supported. In caseswhere the 16-bit application is known to only extract files from itselfand then run a 32-bit application an exception is made. The 16-bitapplication is executed normally and allowed to place the extractedfiles into a temporary location in the base OS file system. Thistemporary location is then added as a shared directory with the virtualOS environment and the 32-bit application that was extracted is thenexecuted in the virtual OS environment.

Since the virtual OS environment file system files are not being used bythe base OS itself, they can be replaced more easily than the actualbase OS files that are normally in use (files that are in-use cannotnormally be replaced except during a reboot). This also allows a rebootafter an installation program to be handled without a reboot beingrequired on the computer itself.

When the OS reboot API is called by a program that is running under avirtual OS environment, the injected DLL function performs theoperations normally handled by the reboot without allowing the OS API toperform a system reboot. All of the applications in the virtual systemare shutdown. The list of files that are queued to be replaced during areboot are then installed. The list of applications that are normallyrun during a system startup are then executed in order. This allowsapplication installation programs that contain require one or morereboots function properly without a reboot actually being performed.

1. A computing architecture, comprising: a base operating system (OS);and at least one virtual OS environment within the base OS, the virtualOS environment having a file system and registry which is independent ofthe base OS.
 2. The computing architecture of claim 1, wherein the baseOS is Windows® or is Windows®-compatible.
 3. The computing architectureof claim 1, further including at least one application running under thevirtual OS environment, and wherein the application shares one or moreof the following with the base OS: networking information, user loginrights, services, hardware information, and clipboard information. 4.The computing architecture of claim 1, further including multiplevirtual OS environments within a single operating system (OS), andwherein a change made in one of the virtual OS environments does notaffect the main OS or any other virtual OS environment.
 5. The computingarchitecture of claim 1, wherein each virtual OS environment contains agroup of installed applications that run independently of each another.6. The computing architecture of claim 1, further including one or moreapplications running under the base OS and each virtual OS environment,and wherein all of the applications run on a single OS desktop.
 7. Thecomputing architecture of claim 1, wherein changes made to configurationinformation with respect to a virtual OS environment does not changeconfiguration information associated with the base OS.
 8. A method ofconfiguring a computer with a base operating system (OS) having a baseOS file system and registry, the method comprising the steps of:creating at least one virtual OS environment under the base OS, eachvirtual OS environment having file system and registry locations whichare independent of the base OS file system and registry locations. 9.The method of claim 8, further including the step of installing at leastone application program under the virtual OS environment; and whereinattempts to access the base OS file system and registry locations areinstead redirected to the virtual OS environment file system orregistry.
 10. The method of claim 9, further including the step ofaltering one or more application programming interfaces (APIs) thataccess the base OS file system and registry directly and indirectly soas to redirect these accesses into the appropriate virtual OSenvironment file system and registry.
 11. The method of claim 10,further including the step of injecting a DLL into every applicationthat is executed.